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METHOD ANP AP PARATUS FOR MANA GING ASSETS OF A CLIENT SIDE 

APPLICATION 



FIELD OF THE INVENTION 

5 

The present invention relates to the client side development process of a client- 
server application. Specifically, the present invention offers a platform-independent 
programming model for efficiently developing and upgrading such client side application. 
Moreover, for each distinct client platform, the present invention manages the platform- 
10 specific programming logistics for delivering to the client machine large size data objects 
(assets) required by the client side application 



BACKGROUND OF THE INVENTION? 

15 Client-server applications prevalent on the Internet today are mostly information 

based: applications serving information to the browser for display. But at the same time, 
exciting possibilities exist for developing more sophisticated client-server applications in at 
least several directions. One possible direction for the future of client-server applications is 
interaction oriented. Instead of browsing rather passively for information, the end users 

20 might want to be able interact with other users on-line (e.g. on-line gaming, on-line 
chatting). Another possible direction for the future of client-server applications is 
presentation oriented. The presentation of information would no longer be confined to the 
usual simple text and graphics data types. The focus of the application development would 
be on taking multi-media to a new level. Novel and effective formats of data types would 

25 continually be created to engage the users* interest and enhance the users' experience with 
richly presented information. Naturally, applications can also be both: offering high level of 
interactivity and presenting media rich information. 



1 
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Commercially, developing more sophisticated client-server applications holds 
exciting promises. The user sessions for interactive applications arc usually much longer 
than a browsing session. So interactive applications might offer an intriguing and effective 
medium for advertising. On the other hand, Web sites having rich media contents can 
5 attract more user visits. So richly presented applications also offers a potentially attractive 
medium for advertising. 

However, developing these applications has been for the most part a slow process 
because of client platform proliferation. This is especially true for the client side application 
1 0 development process of a client-server application. So, before developers build interactive 
on-line applications, they must face and overcome a variety of problems in developing the 
client side application. What stands out among these problems is the proliferation of client 
machine platforms having drastically different characteristics such as CPU performance, 
connection bandwidth, persistent storage types. 

15 

Notwithstanding the existing variety of client platforms available now, the trend of 
new and innovative client platforms will surely continue unabated. Witness recently the 
introduction of a variety of set top boxes, network PC's, and handheld electronic devices. 
Thus, a urgent need arises for containing and handling the complexity of accommodating 
20 different client platforms in developing the client side applications. This is the hardware 
problem for developing client side applications. 

Specifically, the proliferation of client platforms is a problem for developers of 
client side applications because no developer can control what an end user would use as a 
25 client machine. The developers are thus ignorant about the client platform characteristics on 
the client side. In writing any client side application, this ignorance would have to be 
compensated by extensive preparation on developers' part to ensure that the client side 
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application will work with any type (or at least most types) of client platforms in existence. 
Furthermore, given that each client side application can be designed for very different 
objectives, codes accommodating different client platforms in one client side application 
might not be viable for another type of client side application. A new set of codes might be 
5 necessary to accommodate different client platforms in a new on-line application. 
Consequently, developing client side applications is a painstakingly slow process. 

Besides the hardware issue above for developing client side applications, the 
developers face another problem, this time coming from the software side. This problem is 
10 the proliferation of new asset types (data object types) involved in developing these client 
side applications. The assets required by a client side application are traditionally media 
assets such as image data objects, audio data objects, and text data objects. But the term 
"asset" can more broadly refer to any large size data type object needed to be delivered to 
the client in a speedy and precise manner, just like the media assets. 

15 

This proliferation of asset types is inevitable because in order to enhance an end 
user's on-line experience, developers constantly strive to offer a great variety of 
presentation modes. An end user running an interactive on-line application might want to 
listen to a certain audio files, then watch some animation. Each of these data type objects 
20 requires specific handling. By allowing multiple ways for an end user to experience 
information, an application enhances the experience of that information. 

Given that an end user's on-line experience is enhanced by using interesting 
mixture of data object types (asset types), introducing new data object types enhances the 
25 application. But as new data object types become available for incorporating into the 
application, code rewriting can become quite extensive and prohibitive to implement. 
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How are these new data objects displayed to the end users? And for a large size data object, 
how will it be downloaded? These are critical questions that needed to be answered in 
codes by the developers. Thus, what is further needed is a way to handle the proliferation 
of data type objects being created for client side applications. 

5 

To make matter worse for the developers, when considering these software issues 
juxtaposed with the hardware issue of whether client machines of a particular platform can 
display or process the new data objects, developing a client side application can easily 
become a daunting task. In particular, in developing a client side applicadon, developers 
10 face the intricate problem resulting from running various data objects on various client 

platforms. Handling the permutations of different data objects and client platforms entails a 
labor intensive task for developing client side applications. This is the coordination problem 
of simultaneously coping with both the hardware and the software proliferation problems. 

1 5 For the rationale given above, in developing and running an client side application, 

what is needed is a way to overcome the hardware problem of client platform proliferation , 
the software problem of data type object proliferation, and the intricate coordination 
problem of running different data type objects on different client platform. The present 
invention solves both the hardware problem and the software problem involved in 

20 developing and running a client side application. The present invention also solves the 
intricate problem of running various data type objects on various client platforms. 



25 
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SUMMARY OFTHF. INVENTION 

The present invention simplifies the development process of the client side 
application for client-server applications, where the client side application is run on client 
5 machines of drastically different platforms. The present invention provides for the 

developers a powerful and useful infrastructure to quickly and precisely develop a client 
side application. In the process, the present invention ensures delivery of media rich, 
and/or rapidly refreshed images, while freeing the developer to focus on content aspect of 
the application. Specifically, to simplify the development process of a client side 

10 application, the present invention a) provides a platform independent programming model 
as a guide for code development, and b) supports a extensible software component (called 
the Asset Manager) at each client machine's system level for asset management. The 
platform-independent programming model solves problems of proliferation client machine 
platforms. The extensible design of the Asset Manager also solves problems of 

15 proliferating asset data types. Together, the programming model and the Asset Manager 
solves the coordination problem of mixing various different hardware platforms with 
various different software data types. 

Programming Model according to the Present Invention: 

20 

An important aspect of the present invention is its programming model. This 
programming model, when followed, ensures that any asset being used by the client side 
application is being downloaded in an efficient manner, and is being delivered in an 
aggressive manner. In developing an client side application, the developers need to lay out 
25 just once the logistics of how various assets will be used by the application. This 
programming model standardizes the language, the API (Application Programming 
Interface), and the procedures for expressing the logistics of managing and delivering 

5 
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assets needed to run an client side application. Through this programming model, the 
application developers can also prioritize all assets according to their urgency to running 
program by priority levels. Thus, the present invention's programming model offers a 
standardized way to express policies and logistics of utilizing assets according to these 
5 assets' priority levels. For example, a asset may be assigned a high priority level, a 

medium priority level, or a low priority level. Then, the developers can code the policy in a 
standardized way by coding that high priority assets must be downloaded before the 
medium priority assets, and so on. 

10 Asset Manager according to the Present Invention: 

At the core of the present invention is a software component called the Asset 
Manager that is running on each client machine. The Asset Manager is a system level 
software component. It provides an extensible architecture for handling and downloading 

15 new assets and providing them for use by other components in the client system- 
Advantageously, the design of the Asset Manager via data type factories allows 
extensibility of asset data types: a new asset data type can easily be supported by simply 
adding a new data type factory to the Asset Manager without rewriting existing code. 
Moreover, the present invention offers one type of Asset Manager per client machine 

20 platform by tailoring one Asset Manager specifically for each distinct client machine 

platform in order to realize each client machine's full potential. In other words, an. Asset 
Manager can be viewed as a platform-specific system level software component of its 
associated client machine. 

25 In a sense, before the complexity of dealing with multiple client platforms ever 

reach the application developers, the Asset Manager on each client machine is designed to 
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stop that client machine's distinct platform characteristics from ever becoming an issue for 
the developers. Better still, the Asset Manager only has to be designed once. 

For example, for a client machine having high connection bandwidth and small 
5 dynamic memory size, the Asset Manager of this client machine would be designed to 
capitalize on the high connection bandwidth while compensating for small dynamic 
memory size by minimizing memory access. The emphasis here is on repeated download 
and diligent memory purging. In the reverse case, for a client machine having low 
connection bandwidth and large memory size, the Asset Manager of this client machine 

10 would be designed to capitalize on the large memory size by caching a great deal of 
downloaded information and minimizing download. The emphasis here is on caching, 
minimizing downloading. Moreover, as the client application runs, the Asset Manager 
keeps recently accessed assets in the Asset Store, a location in dynamic memory* Then, 
other client applications requiring the same assets can directly access these assets in the 

15 Asset Store. As a result, the use of Asset Store by the Asset Manager minimizes redundant 
asset download, and reduces the latency in switching between different client applications. 

An important role of the Asset Manager is coordinating and finding assets 
wherever they are, pulling them together, ensuring the necessary assets are present for the 

20 client side application to run. Managing the localities of assets is a subde process. Assets 
may be inter alia located on local persistent disk memory, CD-ROM, or the server machine, 
or etc. The Asset Manager keeps track of various asset images in various locations by using 
a global information text file typically called the Manifest. The Manifest is a list of assets 
together with their corresponding asset properties such as description, priority levels, 

25 quality levels. By working in concert with the information specified on the Manifest (by the 
developers or automatically generated), the Asset Manager ensures and delivers all the 
necessary assets with the optimal quality allowed by the client platform resources. The 

' 7 
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Asset Manager will start the application before all the assets are available but continue 
background downloading the remaining assets as the application is running, all 
implemented without compromising the optimal quality allowed by the client platform 
resources. 

5 

Solving the Proliferation of Both Hardware Platforms and Software Data Objects: 

One difficult task for developing a client side application is reconciling variety of 
client platforms and variety of data objects. The present invention, through the deployjnent 
10 of the Asset Manager running on each client machine, reconciles beautifully the hardware 
and software issues. In doing so, the present invention ensures that whatever the resources 
of each client machine are used fully and efficiently. Importantly, because of its flexibility 
to accommodate a wide range of platforms, the present invention enables platform- 
independence beyond that of "Mac. vs. PC". 

15 

In particular, one of the benefits of the present invention is that a developer needs 
only to concentrate on expressing the policies made up of priorities. The detailed 
implementation of carrying out these policies on a variety of client platforms is 
automatically done by the Asset Manager Consequently, from the point of view of a 

20 developer, the proliferation of client machine platforms is no longer an obstacle. The 

programming model and the Asset Manager together ensure the getting of a necessary set of 
assets downloaded to the client machines at the necessary point in time in order for the 
application to proceed in a visually appealing and rational manner, and independent of client 
platforms. Moreover, from the point of view of an end user, the various differences of 

25 client platforms are transparent. 
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To summarize, the programming model offers a standardized way to organize, 
describe, and record assets. It supports multiple levels of quality for each asset and multiple 
levels of priority for assignment to each asset tagged with a certain quality level. In doing 
so, this programming model offers a standardized and convenient way to specify asset 
5 policies. The developers record the assets needed by the application on for example a text 
file called the Manifest. On each client machine, this Manifest is later used by the Asset 
Manager as the client application runs. The Asset Manager downloads the Manifest, and 
refers to it to implement the policies specified in the application's codes. 

10 
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Pfi»EF DE SCRIPTIONS OF THE PR AXy^ qz 

The accompanying drawings, which are incorporated in and form a part of this 
specification, illustrate embodiments of the present invention and, together with the 
5 description, serve to explain the principles of the invention. 

Figure 1 illustrates an exemplary compurer system used as pan of an asset 
management system in accordance with one embodiment of the present invention. 

10 Figure 2 depicts a generic on-line setup for delivering information, where multiple 

clients are running browsers to access the information residing on a HTTP (Hyper Text 
Transfer Protocol) Web server across from the Internet. 



15 



Figure 3 depicts a client-server application more sophisticated than the one depicted 
in Figure 2. It is a chat application being run using the Internet This illustrates an example 
of an interactive on-line application- 



Figure 4 depicts a generic arrangement for running an interactive on-line 
application. These client machines are drawn with different sizes to indicate different 
20 platforms having different characteristics. 

Figures 5A, and 5B are tables summarizing the possible client platform variations 
organized according to connection bandwidths, CPU speeds, and memory sizes. Figure 5 
C gives a board summary of categories that can be used to distinguish various client 
25 platforms. 
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Figure 6 illustrates the preferred embodiment of the present invention, wherein 
various different client platforms are depicted. Some client machines are depicted as having 
local persistent storage's. 

5 Figure 7 illustrates one embodiment of the present invention where one generic 

client machine has multiple local persistent storages. Each of these storage contains a 
different storage image of one asset. 

Figure 8A depicts how assets listed in a Manifest are used in the programming 
10 model of the present invention. Figure 8B depicts the information organization of a generic 
Manifest. 

Figure 9 depicts the internal design of the Asset Manager and illustrates how this 
design provides extensibility of asset data types. Figure 9 also illustrates the concept of the 
15 Asset Store and how it enables switching among client side applications. 

Figure 10 is the flow chart associated with Figure 9. 

Figure 1 1 is a flow chart of showing how the Asset Store facilitates application 
20 switching for the on-line game of Jeopardy, 



25 
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A method and apparatus for management of assets used in running a client side 
application is described. In the following description, for purposes of explanation, 
5 numerous specific details are set forth in order to provide a thorough understanding of the 
present invention. It will be obvious, however, to one skilled in the art that the present 
invention may be practiced without these specific details. In other instances, well-known 
structures and devices are shown in block diagram form in order to avoid obscuring the 
present invention. 

10 

In the following detailed description of the present invention, some of the 
interchangeable key terms relating to the present invention are defined in the section below 
to resolve possible ambiguity and to facilitate future reference. 

15 An asset is any data type object being used by a client side application. An asset 

traditionally refers to a media asset such as an image data object, an audio data object, or a 
text object. But an asset can also be a non-media asset that refers to any data object that 
needs to be delivered to the client machine for a client side application. 

20 An Asset Manager is a system level software component running on a client 

machine. Each distinct client machine platform has its own type of Asset Manager. 

Programming Model is inter alia a methodology of arranging and organizing code 
with a particular set of APIs for achieving certain specific purposes. 

25 
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Quality Layers of an Asset refer to different possible versions of delivering an 
asset. Tn the case of an image asset, possible quality layers are black and white, and lull 
color. 

5 Priority Level of an Asset is the developer's assessment of the delivery order for an 

asset in relation to other assets. 

Manifest is a text file containing a list of assets needed in running a client side 
application. This Manifest also records each asset's associated information such as the 
1 0 quality layer and the priority level to which each asset belongs. 

Persistent Storage refers to any local persistent storage device of a client machine 
such as a harddrive or a CD-ROM. 

15 Furthermore, unless specifically stated otherwise as apparent from the following 

discussions, it is appreciated that throughout the present invention, discussion utilizing 
terms such as "run", "download", "cache", "store", "switch", "fetch", "instantiate", or the 
like, refer to the actions and processes of a computer system, or similar electronic 
computing device. The computer system or similar electronic device manipulates and 

20 transforms data represented as physical (electronic) quantities within the computer system's 
registers and memories into other data similarly represented as physical quantities within 
the computer system memories into other data similarly represented as physical quantities 
within the computer system memories or registers or other such information storage, 
transmission, or display devices. 

25 
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With reference to Figure 1 , portions of the present invention are comprised of the 
computer-readable and computer executable instructions which reside* for example, in 
computer system 10 used as a part of a asset managing system in accordance with one 
embodiment of the present invention. It is appreciated that system 10 of Figure I is 
5 exemplary only and that the present invention can operate within a number of different 
computer systems including general-purpose computer systems, embedded computer 
systems, and stand-alone computer systems specially adapted for client side applications of 
client-server applications. Computer system 10 includes an address/data bus 12 for 
conveying digital information between the various components, a central processor unit 

10 (CPU) 14 for processing the digital information and instructions, a main memory 16 

comprised of volatile random access memory (RAM) for storing the digital information and 
instructions, a non- volatile read only memory (ROM) 18 for storing information and 
instructions of a more permanent nature. In addition, computer system 10 may also include 
a data storage unit 20 (e.g., a magnetic, optical , floppy, or tape drive) for storing vast 

15 amounts of data, and an T/O interface 22 for interfacing with peripheral devices (e.g., 
computer network, modem, mass storage devices, etc.). It should be noted that the 
software component for performing the asset management process can be stored either in 
main memory 16, data storage unit 20, or in an external storage device. Devices which may 
be coupled to computer system 10 include a display device 28 for displaying information to 

20 a computer user, an alphanumeric input device 30 (e.g., a keyboard), and a cursor control 
device 26 (e.g., mouse, trackball, light pen, etc.) for inputting data, selections, updates, 
etc. 

Generic Arrangement for Running an On-line Application: 

25 

Client-server applications prevalent using the Internet today are mostly information 
based. Figure 2 illustrates a generic arrangement for running such simple on-line 

14 
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application over the Internet. Any of the three clients shown here (204, 206 and 208) can 
view the information on a Web page 270 by sending a request across the Internet 202 to a 
HTTP server 200 containing the Web page 270. This HTTP server 200 then sends the Web 
page 270 to the client that made the request. The on-line application in this case is not, 
interactive in the sense that clients do not interact with each other. 

Figure 3 illustrates the setup for running a chat room program, which is an 
interactive on-line application comprises a server application and a client application. This 
.setup is similar to Figure 2 with the addition of an application server 300 hosting the qhat 
server side application 370. The server 300 handles the logistics of various end users 
chatting with each other. In contrast with the on-line application of Figure 2 t this chat 
application 370 is an interactive on-line application. Notice that the chat application 
comprises a server side application 370 and client side applications 374, 376, and 378 (i.e., 
one client side application of the char application per one client machine). 

The chat client applications 304, 306, and 308 run on clients 204. 206, and 208 
respectively. Each of these three chat client applications 304, 306 t and 308 works with 
browsers 274, 276, and 278 respectively to fetch assets 322 and 344, and to drive the 
client user graphic interface. 

Figure 4 illustrates a generic setup similar to that of Figure 3 except that all three 
clients are depicted with different shapes for indicating that these three client machines 
belong to three distinct client platforms. Figure 4 provides a more realistic situation faced 
by a developer of the client side application for an interactive on-line applications. For a 
developer of client side interactive on-line applications, the objective is to deliver media rich 
applications. But the end users can be very far away, making connection bandwidth of the 
client machine a major consideration in delivering large sized asset such as a streaming 

15 
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audio File across the Internet. Moreover, once a certain asset has been downloaded to a 
client machine, the CPU must be powerful enough to handle the sophistication of the asset. 
Finally, information about an end user's machine is unknown to the developer before the 
application launches. Because of these three reasons, developing just the client side 
5 application of a client-server application is a slow and intricate process for the developers. 

Examples of Possible Client Machine Platform Variations: 

Figures 5A~ 5C are tables depicting the client platform variability by organizing 
10 into three tables some of the possible characteristics for client platforms. These tables 
shows more explicitly than does Figure 4 in underscoring the platform proliferation 
problem face by a developer in coding a client side application. 

In particular, Figure 5A uses two aspects of platform characteristics: the extrinsic 
1 5 factor of connection bandwidth available to the client machine 501 , and the intrinsic factor 
of memory size of the client machine 502, On the one hand, the bandwidth characteristics is 
differentiated into High 503 and Low 504, On the other hand, the memory size 
characteristics is differentiated into Large 505 and Small 506. Altogether, this table 522 
presents four possibilities of client platform characteristics (setups): High/Large 511, 
20 High/Small 513, Low/Large 5 12 and Low/Small 5 14. 

In Figure 5 B the connection bandwidth 501 is also used as an aspect of platform 
characteristics as Figure 5 A. But in Figure 5 B, the aspect of CPU speed 509 is used. The 
aspect of CPU speed is differentiated into Fast 507 and Slow 508. Altogether, this table 
25 533 presents four possibilities of client platform characteristics (setups): High/Fast 58 1 , 
High/Slow 583, Low/Fast 582, and Low/Slow 584. 
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In Figure 5 C f a table lists several more aspects of platform characteristics, 
including the aspects of connection bandwidth 501, memory size 502, and CPU speed 
509. The other aspects are persistent storage types 57 1 and software functions available on 
the client machine 572, 

5 

In Figure 6, a preferred embodiment of the present invention is illustrated in detail. 
To take advantage of the programming model offered by the present invention, a developer 
decides on the types of assets 65 1-656 that will be used in the client side application of the 
entire interactive on-line application under design. Also, the developer can offer a gradation 

10 of quality layers for each asset. For example, for each image file asset, the developer can 
easily offer at least two layers of quality: a black and white image file asset as a quality 
layer, and a full color image file asset as the other quality layer- 
In Figure 6, an entire instance of an interactive on-line application (680 and 684 

1 5 combined) comprises the server side application 680 running on the on-line application 
server 300, and the client side application 684 running on top of the browser 274 for the 
client 204. Importantly, the present invention simplifies the development process of the 
client side application. 

20 10 addition to the client side application itself, the developer also supplies the 

Manifest 697 that records the list of assets and their specific properties. The assets 65 1-656 
used by the client application 684 might be located in one location 200 as shown, or they 
could be scattered throughout the Internet. Fortunately, becau.se these assets* locations are 
recorded in the Manifest 697, the application can locate and use these assets by referring to 

25 the Manifest 697. 
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In Figure 6, three clients 204, 206 and 208 are shown across the Internet 202 from 
an on-line application server 300 and an HTTP server 200. These three clients are drawn 
with different shapes to indicate three different machine platforms. Firsdy, these clients 
differ in the types of persistent local storages. Client 204 has both a hard disk 664 and a 
CD-ROM 665, client 206 has only a hard disk 667. and client 208 has no persistent local 
storage at all. Secondly. Client 206 has a more DRAM than Client 208 does. Finally, Client 
206 has low connection bandwidth and Client 208 has high connection bandwidth. 

With reference to Figure 6, each client is running its own Asset Manager tailored to 
the specific strength and weakness of its machine platform. Client 204 is running the Asset 
Manager 634 that takes advantage of the availability of local storages 664 and 665. 



Client 206 is running the Asset Manager 636 that takes advantage of the large 
DRAM size to minimize repeated download through Client (206)'s low bandwidth 

1 S connection 696. The Asset Manager 636 downloads the very minimum number of assets 
having the lowest quality that still allow the application to run in a visually rational manner. 
And as the application runs, the Asset Manager 636 downloads other assets in the 
background so that the enduser can eventually experience high quality for each asset. 
Client 208 is running the Asset Manager 638 that takes advantage of the high connection 

20 bandwidth 698 and minimizes using the DRAM (the browser cache 648 in this case). This 
Asset Manager 638 aggressively purges non-immediate assets from the browser cache to 
continually create room for the needed assets that can be speedily downloaded through the 
high bandwidth connection 698. 

25 Figure 7 illustrates the concept of multiple storage images of an asset. An asset 777 

used by an interactive on-line application (680 and 684) is first stored in certain HTTP 
server 200. As this asset 777 is downloaded to a client 204 having multiple storages such 
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as a hard disk 664 and a CD-ROM 665, the asset 777 is stored and retrieved differently 
depending on the storage type. The asset 777 can be represented by a storage image 755 in 
the hard disk 665, by a reference to a read-only storage image 744 in the CD-ROM 665, or 
by a storage image 766 in the browser cache 644. The client's Asset Manager 634 therefore 
5 keeps records of how and where an original asset is stored by treating the asset 777 as 
having different storage images in different storages. 

The Programming Model provided by the Present Invention: 

10 Figure 8 A depicts the procedures of making a Manifest 697 by a developer who 

follows the present invention's programming model. In essence, Figure 8 A provides the 
schematics of the present invention's programming model for making a Manifest 697. 
First, die developer specifies all of the assets needed by the application 384. Then for each 
asset, the developer designs several levels of quality 805. Also, each layer of quality for 

15 any type of asset is given a quality tag. For example, if asset A is an image file, then the 

developer naturally can have at least two layers of quality, i.e., monochrome and full color. 
After each asset is further differentiated into levels of quality 805, the developer then 
determine the minimum sets of assets required to run the application at a particular point of 
running the application. For example, the developer uses priority tags to classify all assets 

20 into assets designated with priority 1 (for highest priority), with priority 2 (for the next 
highest priority), and so on. As a result, in step 808 the developer codes into asset 
management policies for the logistics of how the application utilizes the assets. Referring 
again to Figure 6, these policies can be coded in the server side application 680, or in the 
client side application 684, or spread between both (680 and 684). 

25 

In conjunction with coding policies expressed via priority levels, the developer also 
records the information about asset quality 804 and asset priority level 806 in the Manifest 
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697. In the final step 877, the Asset Manager 634 refers to the Manifest 697 of the 
application to interact with the client side application 684. 

It should be apparent to one of ordinary skill in the an that the actions of the 
5 developer described supra could be performed manually, or automatedly using computers, 
or partly manually and partly automatedly. The method produces similar results 
irrespective of method implementation details. 

Figure 8 B shows in more detail the information types and formats contained within 
10 a Manifest 697. For each asset listed in the Manifest 697 # a unique ID number 85 1 is given. 
The other parameters of each asset comprise asset data type 852, unique symbolic name 
853 for coding the application, asset file size 855, check sum 856, quality layer 857, URL 
(Uniform Resource Locator) 858 indicating the storage location of the asset, and priority 
level 859. 

15 

The Internal Components of the Asset Manager: 

The Asset Manager is a script interpreting engine that supports and exports an 
interface containing functions for managing the assets needed by the client side application. 

20 The client side application invokes the functions of the Asset Manager to manage all of the 
assets needed to run the application. As the application launches, the Asset Manager object 
and the Asset Registry object are instantiated. Also the Asset Manager comprises a group of 
data type factories objects, with one data object type factory per each assets types supported 
by the Asset Manager. These data type factories are also loaded together with the Asset 

25 Manager. For example, some of the common data type factories are the text data type 

factory for managing text assets, the image data type factory for managing image assets, the 
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to 



audio data type factory for managing audio assets, and so on. All of these factory types are 
registered in the Asset registry. 

When the application requests a particular asset, e.g., an asset with ID equals to 3, 
the Asset Manager looks in the Manifest to find that the data type of asset having ID which 
is equals to 3 is an image data type. Then the Asset Manager calls upon the image data type 
factory to create an object in response to the request. This asset is stored in the central 
location (the Asset Store) for storing all objects created by data type factories in response to 
request. 



Specifically, with reference to Figure 9, the internal components of the Asset 
Manager 634 are discussed. First the client side application of a client-server applicadon, 
say an interactive on-line application, is coded according to the present invention's 
programming model. As the client side application (684 of Figure 6) launched, both the 
15 Asset Manager object 634 and the asset registry object 920 are instantiated, while the 
Manifest 697 becomes downloaded from the application server 300. Instantiation of 
computer objects is well known in the computing arts. The Asset Manager object 634 
comprises a set of data object factories 901-905, with typically one data object factory per 
asset type specified in the Manifest 697. These data object factories 901-905 are registered 
20 to the asset registry object 920. As the application runs, whenever an image asset is 

needed, the image data object factory 902 creates an image asset object 999 in a well known 
location called the Asset Store 940. The image player 942. the audio player 944, and the 
client side application check the Asset Store 940 for matching files and object types. For 
example, the image player 942 would find and play an image asset object 999 inside the 
25 Asset Store 940. 
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With reference to Figure 10, a flow chart is given for outlining the schematics of 
Figure 9. In the step 1002, as the application launches, the Manifest is loaded to the client. 
In step 10O4 T the application notifies the Asset Manager to load the asset with an ID of 3 for 
example. In step 1006, the Asset Manager searches in the Manifest to see that the asset 
5 having ID that is equal to 3 and finds the asset's data type to be the image data type. In the 
step 1008, the Asset Manager pulls from the asset registry the image data object factory in 
order to load this particular image data object. In the step 10 10, the image data object 
factory creates an image object representing the image asset in memory. In the step 1012 T 
the image data object factory adds the image object to the asset store. 

10 

Extensibility of Asset Types for the Asset Manager: 



As discussed above with reference to Figure 9, the Asset Manager supports a group 
of data object factories, wherein each data object factory responsible for managing a 

1 5 specific type of asset. This particular design of the Asset Manager is a powerful feature of 
the present invention becau.se the support for managing a new type of assets can be easily 
added to the Asset Manager without affecting existing codes. As support for any new type 
of assets is added to the Asset Manager, no change to existing code of the Asset Manager is 
necessary. To add support to any new type of assets, the mere addition of a new data type 

20 factory to the Asset Manager would suffice. Consequently, this design of the Asset 
Manager enables the extensibility of asset types. 

For example, with reference to Figure 9, if a new type of asset that needed to be 
supported by the Asset Manager is a "movie" asset, the developer simply codes the movie 
25 data object factory 905 for inclusion in the group of data object factories for the Asset 

Manager 634. Then the deveLoper makes available a movie player 946 on the client machine 
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15 



for playing the movie assets. New code for a new type of asset can be added without 
affecting any existing codes of the client side application or the Asset Manager. 

Another important aspect of the present invention's data type extensibility is the 
ability to support assets of very large sizes such as a streaming data object, without 
affecting existing code. For example, if a very long download of a very large size audio 
asset becomes necessary in running the client side application, the Asset Manager can create 
an illusion that a download has been completed. For a streaming asset such as an audio 
asset, the data objeci representing this audio asset does not have to be fully instantiated in 
the Asset Store by the audio data type factory. That is to say, partially instantiated asset data 
object can be accessed by the client side application as if the asset data object were 
completely instantiated. An audio player can actually begin to play the partially instantiated 
audio data object while the audio data type factory of the Asset Manager continues to 
instantiate the rest of the audio data object 

The Asset Store and switching Applications: 



The Asset Store plays a facilitating role when an end user is switching between 
different interactive on-line applications. Specifically, the Asset Store can store all of the 
20 instantiated assets shared by various client side applications. Then, any of these client side 
applications can directly access and use these instantiated assets. 

With reference to Figure 1 1 , a flow chart is presented to show how the Asset Store 
can be applied for playing the game of JEOPARDY (TM) on-line. For example, if a user 
25 wants to play the game of JEOPARDY (TM) on-line with some other players, the user first 
logs on-line to launch the lobby applicauon of JEOPARDY (TM) to meet potential 
opponents, as outlined in steps 1 102. 1 104 and 1 106. Lobby applications are well known 
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in the online computer gaming arts. Then, in the step 1 108, once the user has decided who 
the other players are, the game application for Jeopardy is launched in the step 1 1 10. 
Finally, ax a game is finished in the step 1114, the user can go back to the "lobby" to find 
some other new opponents by launching the lobby application once again, as outlined in 
5 sequential steps of 1 1 1 8, 1 122, then 1 104. Throughout the whole process, the user would 
have switched between the lobby application and the game application at least twice, as in 
steps 1 124 and 1 122. The Asset Store facilitates the switching between these two 
applications because it retains all of the assets needed by the lobby application when the 
user switches to the game application. So when the user switches back to the lobby 

10 application from the game application, the assets needed by the lobby application are 
already in place in the Asset Store, ready to be used. Similarly, because the Asset Store 
retains all of the assets needed by the game application, as the user switches from the lobby 
application back to the game application, the game application can start right away without 
waiting for its assets to get downloaded. As a result, the Asset Store enhances the user's 

1 5 on-line experience of playing JEOPARDY (TM) because the Asset Store facilitates the 
switching between the lobby application and the game application. 

The foregoing descriptions of specific embodiments of the present invention have 
been presented for purposes of illustration and description. They are not intended to be 

20 exhaustive or to limit the invention to the precise forms disclosed, and obviously many 
modifications and variations are possible in light of the above teaching. The embodiments 
were chosen and described in order to best explain the principles of the invention and its 
practical application, to thereby enable others skilled in the art to best utilize the invention 
and various embodiments with various modification as are suited to the particular use 

25 contemplated. The scope of the invention is intended to be defined by the Claims appended 
hereto and their equivalents. 
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CLAMS 

What is claimed is: 

5 l. For a client-server system having a plurality of different client platforms, a 
computer implemented method of generating a client side application of a client-server 
application, said method comprising: 

providing a programming model to be followed by developers for developing said 

client side application; 

10 providing a programming model to be followed by developers for upgrading said 

client side application; 

generating a file associated with said client side application to record an asset 
required by said client side application, and wherein at least one of said assets is a data 
object; and 

15 managing programming logistics for delivering assets required by said client side 

application, and wherein said managing step is executed on at least one client machine of 
said client-server system by a platform-specific system level software component of a client 
machine. 

20 2. The computer implemented method of Claim 1 , wherein said programming model 
requires steps comprising: 

specifying multiple layers of quality for at least one of said assets, wherein said 
asset is a data object having data types selectable from a group comprising video data 
objects, audio data objects, code data objects, data chunk data objects, graphic data objects, 
25 image data objects; 

setting a level of priority for delivering at least one of said assets to said client 
machine; 

25 
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centralizing in said file information associated with at least one of said assets 

required by said client application; 

designing asset delivering policies with said centralized information of said file; and 
providing extensibility of new asset data types, wherein adding new asset data 

types does not require changing existing code. 

3 . The computer implemented method of Claim 2, wherein said multiple layers of 
quality comprise: 

a plurality of audio quality layers ranging from low fidelity to high fidelity; and 
a plurality of image quality layers ranging from monochrome to full color. 

4 . The computer implemented method of Claim 2, whetein said priority levels are 
ranked by positive integers, and an integer one designates an asset having the highest 
download priority. 

5 . The computer implemented method of Claim 2, wherein for each said asset, said 
centralized information in said file comprises: 

a field of unique ID number, 

a field of data type; and 

a field of unique symbolic name. 

6. The computer implemented method of Claim 2, wherein said policies need to be 
coded only once for each client platform, and wherein said policies are coded with said 
download priorities specified in said file. 

7. The computer implemented method of Claim 2. wherein said addition of new asset 
data types is implemented by adding a data object factory per one new asset data type in 
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said software component without affecting existing code of said software component and 
said client side application. 

8 . The computer implemented method of Claim I . wherein said managing step further 
5 comprises the steps of: 

customizing said asset management software component for each type of client 
platform, wherein said software component manages asset delivery for said client 
application running on each client machine of said client-server system; 
fetching said text file to each said client machine; 
10 prioritizing download ordering of assets with reference to said file; 

unifying multiple storage images of each said asset, wherein each of said storage 
images represents said asset in a distinct persistent memory storage location; 

storing in a central memory location all assets shared by a plurality of client 
applications, wherein said central memory location is termed an Asset Store; 
1 5 minimizing asset download to avoid interrupting sessions of said client side 

application session; 

9 . The computer implemented method of Claim 8 , wherein each said type of client 
platform having characteristics ranges: 
20 from high to low connection bandwidths; 

from large to small dynamic memory sizes; 

from high to low CPU processing speeds; and 

from several to no persistent memory storages. 

25 10. The computer implemented method of Claim 8, wherein said client application can 
start before all of said required assets are available, and wherein said software component 
continues background downloading not-yet downloaded assets. 
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1 1 . The computer implemented method of Claim 8, wherein said multiple storage 
images are uniquely keyed and encoded in addition to said asset located on a HTTP Web 
server, and wherein said software component use available persistently stored storage 

5 images of said assets to avoid downloading said asset from said HTTP Web server. 

1 2 . The computer implemented method of Claim 8, wherein said shared assets 
minimizes latency in switching between applications. 

1 3 . The computer implemented method of Claim 8, wherein said minimizing step 
comprises: 

searching said text file for all assets having priority levels lower than assets having 
the highest priority level; 

downloading said assets having a highest priority level; 

starting said client application as soon as said assets having the highest priority level 
arc completely downloaded; 

downloading said lower priority assets in the background while said client 
application is in session: and 

downloading said lower priority assets while said client application is in between 
sessions. 

1 4. For a client-server system having a plurality of client machines from different client 
platforms, a computer-readable medium having stored thereon instructions for causing said 
client machines to deliver assets required by a client side application of a client-server 

25 application, comprising code for supporting: 

a plurality of assets fetched from a plurality of servers; 
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a server component generating a file to list said required assets and to specify 
properties associated with said assets; 

a management component for delivering said assets in accordance to said plurality 

of policies; and 

5 an extensible set of data object factories, wherein each of said data object factories 

is associated with a distinct asset data type. 

15. The computer-readable medium of Claim 14, wherein each said asset is a data 
object selectable from a group comprising video data objects, audio data objects, code-data 

10 objects, data chunk data objects, graphic data objects, and image data objects. 

16. The computer-readable medium of Claim 14, wherein said file is a manifest 
associated with said client side application, said manifest comprising: 

a field of unique ID number for each said asset; 
15 a field of data type for each said asset; and 

a field of unique symbolic name for each said asset. 

17. The computer-readable medium of Claim 14, wherein the priority levels assignable 
to each of said assets are designated by positive integers, wherein an integer one designates 

20 an asset with the highest download priority level. 

18. The computer-readable medium of Claim 14, wherein for at least one of said client 
machines, said policies specify delivering a necessary platform-specific subset of said 
assets at a necessary point in time in order for said client side application to proceed in a 

25 visually appealing and rational manner. 
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1 9 . The computer-readable medium of Claim 14, wherein said management component 
downloads said assets to at least one of said client machines according to said policies, and 
wherein said management component fetches said assets directly from a plurality of local 
persistent memory locations, provided said assets have been downloaded and stored in said 

5 plurality of local persistent memory locations, 

20. The computer-readable medium of Claim 14, wherein at least one of said data object 
factories, in the dynamic memory of said client machines, instantiates a data object 
representing an asset with the same data type as said data object. 

10 

2 1 . The computer-readable medium of Claim 20» wherein at least one of said 
instantiated data object is stored in a common dynamic memory location, wherein another 
client side application requiring such said data object can direcdy access said data object 
without any further data object instantiation. 

15 

22. The computer-readable medium of Claim 14, wherein said servers are HTTP Web 
servers. 

23. The computer-readable medium of Claim 14, further comprising a plurality of 
20 priority levels assigned to said assets. 

24. The computer-readable medium of Claim 14, further comprising a plurality of 
policies for delivering said assets to said client machines. 

25 25 . The computer implemented method of Claim 2, wherein for each said asset, said 
centralized information in said file further comprises: 
afield of URL; 
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a field of quality; 

a field of checksum; and 

a field of download priority level. 

5 26 . The computer-readable medium of Claim 1 4, wherein said file is a manifest 
associated with said client side application, said manifest further comprising: 
a field of URL for each said a<wet; 
a field of asset file size for each said asset; 
a field of quality for each said asset; 
10 a field of checksum for each said asset; and 

a field of download priority level for each said asset. 
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(57) Abstract: The present invention simplifies the development of a client side application for a client-server application, wherein 
such a client side application typically runs on multiple clients having drastically different platform characteristics. To simplify the 
development process of a client side application, the present invention a) provides a programming model as a guide for code develop- 
ment, and b) supports a software component at each client machine's system level for asset management. The programming model 
guides the coding development of the client side application in a standardized and systematic manner. It also allows the developers to 
write codes that are platform-independent. Asset management is automated by a client system level software component (called the 
Asset Manager) running on each client's side. The Asset Manager of each client is tailored specifically for maximizing the capability 
of the client machine platform. Moreover, the Asset Manager of each client enables the development of client platform-independent 
code. In addition, the design of the Asset Manager via data type factories allows extensibility of media asset types; a new asset 
data type can easily be supported by simply adding a new data type factory to the Asset Manager without rewriting existing code. 
Finally, the Asset Manager uses a central location called the Asset Store to store assets shared by different client side applications, 
thus facilitating the speed of switching among these applications. 
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IURTHOD AND APPARATUS FO R MANAGING ASSETS OF ^ CLIENT SIP5 

APPLICATION 

PJJPl H OF TKR INVENTION 

5 

The present invention relates to the client side development process of a client- 
server application. Specifically, the present invention offers a platform-independent 
programming model for efficiently developing and upgrading such client side application. 
Moreover, for each distinct client platform, the present invention manages the platform- 
10 specific programming logistics for delivering to the client machine large size data objects 
(assets) required by the client side application 



R AfKOROUND OF THE INVENTION 

15 Client-server applications prevalent on the Internet today are mostly information 

based: applications serving information to the browser for display. But at the same time, 
exciting possibilities exist for developing more sophisticated client-server applications in at 
least several directions. One possible direction for the future of client-server applications is 
interaction oriented. Instead of browsing rather passively for information, the end users 

20 might want to be able interact with other users on-line (e.g. on-line gaming, on-line 
chatting). Another possible direction for the future of client-server applications is 
presentation oriented. The presentation of information would no longer be confined to the 
usual simple text and graphics data types. The focus of the application development would 
be on taking multi-media to a new level. Novel and effective formats of data types would 

25 continually be created to engage the users' interest and enhance the users' experience with 
richly presented information. Naturally, applications can also be both: offering high level of 
interactivity and presenting media rich information. 
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Commercially, developing more sophisticated client-server applications holds 
exciting promises. The user sessions for interactive applications are usually much longer 
than a browsing session. So interactive applications might offer an intriguing and effective 
medium for advertising. On the other hand, Web sites having rich media contents can 
5 attract more user visits. So richly presented applications also offers a potentially attractive 
medium for advertising. 

However, developing these applications has been for the most part a slow process 
because of client platform proliferation. This is especially true for the client side application 
10 development process of a client-server application. So, before developers build interactive 
on-line applications, they must face and overcome a variety of problems in developing the 
client side application. What stands out among these problems is the proliferation of client 
machine platforms having drastically different characteristics such as CPU performance, 
connection bandwidth, persistent storage types. 

15 

Notwithstanding the existing variety of client platforms available now, the trend of 
new and innovative client platforms will surely continue unabated. Witness recently the 
introduction of a variety of set top boxes, network PC's, and handheld electronic devices. 
Thus, a urgent need arises for containing and handling the complexity of accommodating 
20 different client platforms in developing the client side applications. This is the hardware 
problem for developing client side applications. 

Specifically, the proliferation of client platforms is a problem for developers of 
client side applications because no developer can control what an end user would use as a 
25 client machine. The developers are thus ignorant about the client platform characteristics on 
the ckent side. In writing any client side application, this ignorance would have to be 
compensated by extensive preparation on developers' part to ensure that the client side 
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10 



15 



application will work with any type (or at least most types) of client platforms in existence. 
Furthermore, given that each client side application can be designed for very different 
objectives, codes accommodating different client platforms in one client side application 
might not be viable for another type of client side application. A new set of codes might be 
necessary to accommodate different client platforms in a new on-line application. 
Consequently, developing client side applications is a painstakingly slow process. 

Besides the hardware issue above for developing client side applications, the 
developers face another problem, this time coming from the software side. This problem is 
the proliferation of new asset types (data object types) involved in developing these client 
side applications. The assets required by a client side application are traditionally media 
assets such as image data object., audio data objects, and text data objects. But the term 
"asset" can more broadly refer to any large size data type object needed to be delivered to 
the client in a speedy and precise manner, just like the media assets. 



to 



This proliferation of asset types is inevitable because in order to enhance an end 
user's on-line experience, developers constantly strive to offer a great variety of 
presentation modes. An end user running an interactive on-line application might want 
listen to a certain audio files, then watch some animation. Each of these data type object? 
20 requires specific handling. By allowing multiple ways for an end user to experience 
information, an application enhances the experience of that information. 

Given that an end user's on-line experience is enhanced by using interesting 
mixture of data object types (asset types), introducing new data object types enhances the 
25 application. But as new data object types become available for incorporating into the 
application, code rewriting can become quite extensive and prohibitive to implement 
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How are these new data objects displayed to the end users? And for a large size data object, 
how will it be downloaded? These are critical questions that needed to be answered in 
codes by the developers. Thus, what is farther needed is a way to handle the proliferation 
of data type objects being created for client side applications. 

5 

To make matter worse for the developers, when considering these software issues 
juxtaposed with the hardware issue of whether client machines of a particular platform can 
display or process the new data objects, developing a client side application can easily 
become a daunting task. In particular, in developing a client side application, developers 
10 face the intricate problem resulting from running various data objects on various client 

platforms. Handling the permutations of different data objects and client platforms entails a 
labor intensive task for developing client side applications. This is the coordination problem 
of simultaneously coping with both the hardware and the software proliferation problems. 

15 For the rationale given above, in developing and running an client side application, 

what is needed is a way to overcome the hardware problem of client platform proliferation , 
the software problem of data type object proliferation, and the intricate coordination 
problem of running different data type objects on different client platform. The present 
invention solves both the hardware problem and the software problem involved in 

20 developing and running a client side application. The present invention also solves the 
intricate problem of running various data type objects on various client platforms. 



25 
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SUMMARY OF THE INVENTION 

The present invention simplifies the development process of the client side 
application for client-server applications, where the client side application is run on client 

5 machines of drastically different platforms. The present invention provides for the 

developers a powerful and useful infrastructure to quickly and precisely develop a client 
side application. In the process, the present invention ensures delivery of media rich, 
and/or rapidly refreshed images, while freeing the developer to focus on content aspect of 
the application. Specifically, to simplify the development process of a client side 

10 application, the present invention a) provides a platform independent programming model 
as a guide for code development, and b) supports a extensible software component (called 
the Asset Manager) at each client machine's system level for asset management. The 
platform-independent programming model solves problems of proliferation client machine 
platforms. The extensible design of the Asset Manager also solves problems of 

15 proliferating asset data types. Together, the programming model and the Asset Manager 
solves the coordination problem of mixing various different hardware platforms with 
various different software data types. 

Programming Model according to the Present Invention: 

20 

An important aspect of the present invention is its programming model. This 
programming model, when followed, ensures that any asset being used by the client side 
application is being downloaded in an efficient manner, and is being delivered in an 
aggressive manner. In developing an client side application, the developers need to lay out 
25 just once the logistics of how various assets will be used by the application. This 
programming model standardizes the language, the API (Application Programming 
Interface), and the procedures for expressing the logistics of managing and delivering 

5 
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assets needed to run an client side application. Through this programming model, the 
application developers can also prioritize all assets according to their urgency to running 
program by priority levels. Thus, the present invention's programming model offers a 
standardized way to express policies and logistics of utilizing assets according to these 
5 assets* priority levels. For example, a asset may be assigned a high priority leveL a 

medium priority level, or a low priority level. Then, the developers can code the policy in a 
standardized way by coding that high priority assets must be downloaded before the 
medium priority assets, and so on. 

10 Asset Manager according to the Present invention: 

At the core of the present invention is a software component called the Asset 
Manager that is running on each client machine. The Asset Manager is a system level 
software component. It provides an extensible architecture for handling and downloading 

15 new assets and providing them for use by other components in the client system. 
Advantageously, the design of the Asset Manager via data type factories allows 
extensibility of asset data types: a new asset data type can easily be supported by simply 
adding a new data type factory to the Asset Manager without rewriting existing code. 
Moreover, the present invention offers one type of Asset Manager per client machine 

20 platform by tailoring one Asset Manager specifically for each distinct client machine 

platform in order to realize each client machine's full potential. In other words, an. Asset 
Manager can be viewed as a platform-specific system level software component of its 
associated client machine. 

25 In a sense, before the complexity of dealing with multiple client platforms ever 

reach the application developers, the Asset Manager on each client machine is designed to 

6 
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stop that client machine's distinct platform characteristics from ever becoming an issue for 
the developers. Better still, the Asset Manager only has to be designed once. 

For example, for a client machine having high connection bandwidth and small 
5 dynamic memory size, the Asset Manager of this client machine would be designed to 
capitalize on the high connection bandwidth while compensating for small dynamic 
memory size by minimizing memory access. The emphasis here is on repeated download 
and diligent memory purging. In the reverse case, for a client machine having low 
connection bandwidth and large memory size, the Asset Manager of this client machine 
10 would be designed to capitalize on the large memory size by caching a great deal of 
downloaded information and minimizing download. The emphasis here is on caching, 
minimizing downloading. Moreover, as the client application runs, the Asset Manager 
keeps recently accessed assets in the Asset Store, a location in dynamic memory. Then, 
other client applications requiring the same assets can directly access these assets in the 
1 5 Asset Store. As a result, the use of Asset Store by the Asset Manager minimizes redundant 
asset download, and reduces the latency in switching between different client applications. 

An important role of the Asset Manager is coordinating and finding assets 
wherever they are, pulling them together, ensuring the necessary assets are present for the 

20 client side application to run. Managing the localities of assets is a subtle process. Assets 
may be inter alia located on local persistent disk memory, CD-ROM, or the server machine, 
or etc. The Asset Manager keeps track of various asset images in various locations by using 
a global information text file typically called the Manifest. The Manifest is a list of assets 
together with their corresponding asset properties such as description, priority levels, 

25 quality levels. By working in concert with the information specified on the Manifest (by the 
developers or automatically generated), the Asset Manager ensures and delivers all the 
necessary assets with the optimal quality allowed by the client platform resources. The 
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Asset Manager will start the application before all the assets are available but continue 
background downloading the remaining assets as the application is running, all 
implemented without compromising the optimal quality allowed by the client platform 
resources. 

5 

Solving the Proliferation of Both Hardware Platforms and Software Data Objects: 

One difficult task for developing a client side application is reconciling variety of 
client platforms and variety of data objects. The present invention, through the deployment 
10 of the Asset Manager running on each client machine, reconciles beautifully the hardware 
and software issues. In doing so. the present invention ensures that whatever the resources 
of each client machine are used fully and efficiently. Importantly, because of its flexibility 
to accommodate a wide range of platforms, the present invention enables platform- 
independence beyond that of "Mac. vs. PC". 

15 

In particular, one of the benefits of the present invendon is that a developer needs 
only to concentrate on expressing the policies made up of priorities. The detailed 
implementadon of carrying out these policies on a variety of client platforms is 
automatically done by the Asset Manager. Consequently, from the point of view of a 

20 developer, the proliferation of client machine platforms is no longer an obstacle. The 

programming model and the Asset Manager together ensure the getting of a necessary set of 
assets downloaded to the client machines at the necessary point in time in order for the 
application to proceed in a visually appealing and rational manner, and independent of client 
platforms. Moreover, from the point of view of an end user, the various differences of 

25 client platforms are transparent. 
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To summarize, the programming model offers a standardized way to organize, 
describe, and record assets. It supports multiple levels of quality for each asset and multiple 
levels of priority for assignment to each asset tagged with a certain quality level. In doing 
so, this programming model offers a standardized and convenient way to specify asset 
5 policies. The developers record the assets needed by the application on for example a text 
file called the Manifest. On each client machine, this Manifest is later used by the Asset 
Manager as the client application runs. The Asset Manager downloads the Manifest, and 
refers to it to implement the policies specified in the application's codes. 
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RRjlFF DESCRIPTIONS OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and form a part of this 
specification, illustrate embodiments of the present invention and, together with the 
5 description, serve to explain the principles of the invention. 

Figure 1 illustrates an exemplary compurer system used as part of an asset 
management system in accordance with one embodiment of the present invention. 

10 Figure 2 depicts a generic on-line setup for delivering information, where multiple 

clients are running browsers to access the information residing on a HTTP (Hyper Text 
Transfer Protocol) Web server across from the Internet. 

Figure 3 depicts a client-server application more sophisticated than the one depicted 
15 in Figure 2. It is a chat application being run using the Internet. This illustrates an example 
of an interactive on-line application. 

Figure 4 depicts a generic arrangement for running an interactive on-line 
application. These client machines are drawn with different sizes to indicate different 
20 platforms having different characteristics. 

Figures 5A, and 5B are tables summarizing the possible client platform variations 
organized according to connection bandwidths, CPU speeds, and memory sizes. Figure 5 
C gives a board summary of categories that can be used to distinguish various client 
25 platforms. 
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Figure 6 illustrates the preferred embodiment of the present invention, wherein 
various different client platforms are depicted. Some client machines are depicted as having 
local persistent storage's. 

5 Figure 7 illustrates one embodiment of the present invention where one generic 

client machine has multiple local persistent storages. Each of these storage contains a 
different storage image of one asset. 

Figure 8A depicts how assets listed in a Manifest are used in the programming 
10 model of the present invention. Figure 8B depicts the information organization of a generic 
Manifest. 

Figure 9 depicts the internal design of the Asset Manager and illustrates how this 
design provides extensibility of asset data types. Figure 9 also illustrates the concept of the 
1 5 Asset Store and how it enables switching among client side applications. 

Figure 10 is the flow chart associated with Figure 9. 

Figure 1 1 is a flow chart of showing how the Asset Store facilitates application 
20 switching for the on-line game of Jeopardy, 



25 
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A method and apparatus for management of assets used in running a client side 
application is described. In the following description, for purposes of explanation, 
5 numerous specific details are set forth in order to provide a thorough understanding of the 
present invention.lt will be obvious, however, to one skilled in the art that the present 
invention may be practiced without these specific details. In other instances, well-known 
structures and devices are shown in block diagram form in order to avoid obscuring the 
present invention. 

10 

In the following detailed description of the present invention, some of the 
interchangeable key terms relating to the present invention are defined in the section below 
to resolve possible ambiguity and to facilitate future reference. 

15 An asset is any data type object being used by a client side application. An asset 

traditionally refers to a media asset such as an image data object, an audio data object, or a 
text object. But an asset can also be a non-media asset that refers to any data object that 
needs to be delivered to the client machine for a client side application. 

20 An Asset Manager is a system level software component running on a client 

machine. Each distinct client machine platform has its own type of Asset Manager. 

Programming Model is inter alia a methodology of arranging and organizing code 
with a particular set of APIs for achieving certain specific purposes. 

25 
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Quality Layers of an Asset refer to different possible versions of delivering an 
asset. Tn the case of an image asset, possible quality layers are black and white, and full 
color, 

5 Priority Level of an Asset is the developer's assessment of the delivery order for an 

asset in relation to other assets. 

Manifest is a text file containing a list of assets needed in running a client side 
application. This Manifest also records each asset's associated information such as the 
10 quality layer and the priority level to which each asset belongs. 

Persistent Storage refers to any local persistent storage device of a client machine 
such as a harddrive or a CD-ROM. 

15 Furthermore, unless specifically stated otherwise as apparent from the following 

discussions, it is appreciated that throughout the present invention, discussion utilizing 
terms such as "run", "download", "cache", "store", "switch", "fetch", "instantiate", or the 
like, refer to the actions and processes of a computer system, or similar electronic 
computing device. The computer system or similar electronic device manipulates and 

20 transforms data represented as physical (electronic) quantities within the computer system's 
registers and memories into other data .similarly represented as physical quantities within 
the computer system memories into other data similarly represented as physical quantities 
within the computer system memories or registers or other such information storage, 
transmission, or display devices. 

25 
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With reference to Figure 1 , portions of the present invention are comprised of the 
computer-readable and computer executable instructions which reside, for example, in 
computer system 10 used as a part of a asset managing system in accordance with one 
embodiment of the present invention. It is appreciated that system 10 of Figure I is 
5 exemplary only and that the present invention can operate within a number of different 
computer systems including general-purpose computer systems, embedded computer 
systems, and stand-alone computer systems specially adapted for client side applications of 
client-server applications. Computer system 10 includes an address/data bus 12 for 
conveying digital information between the various components, a central processor unit 
10 (CPU) 14 for processing the digital information and instructions, a main memory 1 6 

comprised of volatile random access memory (RAM) for storing the digital information and 
instructions, a non- volatile read only memory (ROM) 18 for storing information and 
instructions of a more permanent nature. In addition, computer system 10 may also include 
a data storage unit 20 (e.g., a magnetic, optical , floppy, or tape drive) for storing vast 
1 5 amounts of data, and an T/O interface 22 for interfacing with peripheral devices (e.g. , 
computer network, modem, mass storage devices, etc.). It should be noted that the 
software component for performing the asset management process can be stored either in 
main memory 16, data storage unit 20, or in an external storage device. Devices which may 
be coupled to computer system 10 include a display device 28 for displaying information to 
20 a computer user, an alphanumeric input device 30 (e.g., a keyboard), and a cursor control 
device 26 (e.g., mouse, trackball, light pen, etc.) for inputting data, selections, updates, 
etc. 



25 



Generic Arrangement for Running an On-line Application: 

Client-server applications prevalent using the Internet today are mostly information 
based. Figure 2 illustrates a generic arrangement for running such simple on-line 
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application over the Internet. Any of the three clients shown here (204, 206 and 208) can 
view the information on a Web page 270 by sending a request across the Internet 202 to a 
HTTP server 200 containing the Web page 270. This HTTP server 200 then sends the Web 
page 270 to the client that made the request. The on-line application in this case is not, 
5 interactive in the sense that clients do not interact with each other. 

Figure 3 illustrates the setup for running a chat room program, which is an 
interactive on-line application comprises a server application and a client application. This 
setup is similar to Figure 2 with the addition of an application server 300 hosting the qhat 
10 server side application 370. The server 300 handles the logistics of various end users 
chatting with each other. In contrast with the on-line application of Figure 2 t this chat 
application 370 is an interactive on-line application. Notice that the chat application 
comprises a server side application 370 and client side applications 374, 376, and 378 (i.e., 
one client side application of the chat application per one client machine). 



15 



20 



The chat client applications 304. 306, and 308 run on clients 204. 206. and 208 
respectively. Each of these three chat client applications 304, 306, and 308 works with 
browsers 274, 276, and 278 respectively to fetch assets 322 and 344, and to drive the 
client user graphic interface. 



Figure 4 illustrates a generic setup similar to that of Figure 3 except that all three 
clients are depicted with different shapes for indicating that these three client machines 
belong to three distinct client platforms. Figure 4 provides a more realistic situation faced 
by a developer of the client side application for an interactive on-line applications. For a 
25 developer of client side interactive on-line applications, the objective is to deliver media rich 
applications. But the end users can be very far away, making connection bandwidth of the 
client machine a major consideration in delivering large sized asset such as a streaming 
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audio file across the Internet. Moreover, once a certain asset has been downloaded to a 
client machine, the CPU must be powerful enough to handle the sophistication of the asset. 
Finally, information about an end user's machine is unknown to the developer before the 
application launches. Because of these three reasons, developing just the client side 
5 application of a client-server application is a slow and intricate process for the developers. 

Examples of Possible Client Machine Platform Variations: 

Figures 5A~ 5C are tables depicting the client platform variability by organizing 
10 into three tables some of the possible characteristics for client platforms. These tables 
shows more explicitly than does Figure 4 in underscoring the platform proliferation 
problem face by a developer in coding a client side application. 

In particular, Figure 5 A uses two aspects of platform characteristics: the extrinsic 
1 5 factor of connection bandwidth available to the client machine 50 1 , and the intrinsic factor 
of memory size of the client machine 502. On the one hand, the bandwidth characteristics is 
differentiated into High 503 and Low 504. On the other hand, the memory size 
characteristics is differentiated into Large 505 and Small 506. Altogether, this table 522 
presents four possibilities of client platform characteristics (setups): High/Large 511, 
20 High/Small 513, Low/Large 512 and Low/Small 514, 

In Figure 5 B the connection bandwidth 501 is also used as an aspect of platform 
characteristics as Figure 5 A. But in Figure 5 B, the aspect of CPU speed 509 is used. The 
aspect of CPU speed is differentiated into Fast 507 and Slow 508. Altogether, this table 
25 533 presents four possibilities of client platform characteristics (setups): High/Fast 58 1 , 
High/Slow 583, Low/Fast 582, and Low/Slow 584. 
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In Figure 5C,a table lists several more aspects of platform characteristics, 
including the aspect* of connection bandwidth 501, memory size 502, and CPU speed 
509. The other aspects are persistent storage types 571 and software functions available on 
the client machine 572, 

5 

In Figure 6, a preferred embodiment of the present invention is illustrated in detail. 
To take advantage of the programming model offered by the present invention, a developer 
decides on the types of assets 65 1-656 that will be used in the client side application of the 
entire interactive on-line application under design. Also, the developer can offer a gradation 
10 of quality layers for each asset. For example, for each image file asset, the developer can 
easily offer at least two layers of quality: a black and white image file asset as a quality 
layer, and a full color image file asset as the other quality layer. 

In Figure 6, an entire instance of an interactive on-line application (680 and 684 
1 5 combined) comprises the server side application 680 running on the on-line application 
server 300, and the client side application 684 running on top of the browser 274 for the 
client 204. Importantly, the present invention simplifies the development process of the 
client side application. 

20 In addition to the client side application itself, the developer also supplies the 

Manifest 697 that records the list of assets and their specific properties. The assets 65 1-656 
used by the client application 684 might be located in one location 200 as shown, or they 
could be scattered throughout the Internet. Fortunately, because these assets 1 locations are 
recorded in the Manifest 697, the application can locate and use these assets by referring to 

25 the Manifest 697. 
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in Figure 6, three clients 204, 206 and 208 are shown across the Internet 202 from 
an on-line application server 300 and an HTTP server 200. These three clients are drawn 
with different shapes to indicate three different machine platforms. Firsdy, these chents 

5 CD-ROM665,client206hasonlyaharddislc667.andclient 208 has no persistent local 
storage at all. Secondly. Client 206 has a more DRAM than Client 208 does. Finally, Client 
206 has low connection bandwidth and Client 208 has high connection bandwidth. 

With reference to Figure 6, each client is running its own Asset Manager tailored to 
1 0 the specific strength and weakness of its machine platform. Client 204 is running the Asset 
Manager 634 that takes advantage of the availability of local storages 664 and 665. 

Client 206 is running the Asset Manager 636 that takes advantage of the large 
DRAM size to minimize repeated download through Client (206)' s low bandwidth 
15 connection 696. The Asset Manager 636 downloads the very minimum number of assets 
having the lowest quality that still allow the application to run in a visually rational manner. 
And » the application runs, the Asset Manager 636 downloads other assets in the 
background so that the enduscr can eventually experience high quality for each asset. 
Client 208 is running the Asset Manager 638 that takes advantage of the high connection 
20 bandwidth 698 and minimizes using the DRAM (the browser cache 648 in this case). This 
Asset Manager 638 aggressively purges non-immediate assets from the browser cache to 
continually create room for the needed assets that can be speedily downloaded through the 
high bandwidth connection 698. 

25 Figure 7 illustrates the concept of multiple storage images of an asset. An asset 777 

used by an interactive on-line application (680 and 684) is first stored in certain HTTP 
server 200. As this asset 777 is downloaded to a client 204 having multiple storages such 
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as a hard disk 664 and a CD-ROM 665, the asset 777 is stored and retrieved differently 
depending on the storage type. The asset 777 can be represented by a storage image 755 in 
the hard disk 665, by a reference to a read-only storage image 744 in the CD-ROM 665. or 
by a storage image 766 in the browser cache 644. The client's Asset Manager 634 therefore 
5 keeps records of how and where an original asset is stored by treating the asset 777 as 
having different storage images in different storages. 

The Programming Model provided by the Present Invention: 

10 Figure 8 A depicts the procedures of making a Manifest 697 by a developer who 

follows the present invention's programming model. In essence. Figure 8 A provides the 
schematics of the present invention's programming model for making a Manifest 697. 
First, die developer specifies all of the assets needed by the application 384. Then for each 
asset, the developer designs several levels of quality 805. Also, each layer of quality for 
15 any type of asset is given a quality tag. For example, if asset A is an image file, then the 

developer naturally can have at least two layers of quality, i.e.. monochrome and full color. 
After each asset is further differentiated into levels of quality 805, the developer then 
determine the minimum sets of assets required to run the application at a particular point of 
running the application. For example, the developer uses priority tags to classify all assets 
20 into assets designated with priority 1 (for highest priority), with priority 2 (for the next 
highest priority), and so on. As a result, in step 808 the developer codes into asset 
management policies for the logistics of how the application utilizes the assets. Referring 
again to Figure 6, these policies can be coded in the server side application 680, or in the 
client side application 684, or spread between both (680 and 684). 



25 



In conjunction with coding policies expressed via priority levels, the developer also 
records the information about asset quality 804 and asset priority level 806 in the Manifest 
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697. In the final step 877. the Asset Manager 634 refers to the Manifest 697 of the 
application to interact with the client side application 684. 

It should be apparent to one of ordinary skill in the an that the actions of the 
5 developer described supra could be performed manually, or automatedly using computers, 
or partly manually and partly automatedly. The method produces similar results 
irrespective of method implementation details. 

Figure 8 B shows in more detail the information types and formats contained within 
10 a Manifest 697. For each asset listed in the Manifest 697. a unique ID number 85 1 is given. 
The other parameters of each asset comprise asset data type 852. unique symbolic name 
853 for coding the application, asset file size 855, check sum 856, quality layer 857, URL 
(Uniform Resource Locator) 858 indicating the storage location of the asset, and priority 
level 859. 
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The internal Components of the Asset Manager: 



The Asset Manager is a script interpreting engine that supports and exports an 
interface containing functions for managing the assets needed by the client side application. 

20 The client side application invokes the functions of the Asset Manager to manage all of the 
assets needed to run the application. As the application launches, the Asset Manager object 
and the Asset Registry object are instantiated. Also the Asset Manager comprises a group of 
data type factories objects, with one data object type factory per each assets types supported 
by the Asset Manager. These data type factories are also loaded together with the Asset 

25 Manager. For example, some of the common data type factories are the text data type 

factory for managing text assets, the image data type factory for managing image assets, the 
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audio daia type factory for managing audio assets, and so on. All of these factory types are 
registered in the Asset registry. 

When the application requests a particular asset, e.g., an asset with ID equals to 3. 
the Asset Manager looks in the Manifest to find that the data type of asset having ID which 
is equals to 3 is an image data type. Then the Asset Manager calls upon the image data type 
factory to create an object in response to the request. This asset is stored in the central 
location (the Asset Stole) for storing all objects created by data type factories in response to 
request. 



10 



15 



Specifically, with reference to Figure 9. the internal components of the Asset 
Manager 634 are discussed. First the client side application of a client-server applicadon. 
say an interactive on-line application, is coded according to the present invention's 
programming model. As the client side application (684 of Figure 6) launched, both the 
Asset Manager object 634 and the asset registry object 920 are instantiated, while the 
Manifest 697 becomes downloaded from the application server 300. Instantiation of 
computer objects is well known in the computing arts. The Asset Manager object 634 
comprises a set of data object factories 901-905. with typically one data object factory per 
asset type specified in the Manifest 697. These data object factories 901-905 are registered 
20 to the asset registry object 920. As the application runs, whenever an image asset is 

needed, the image data object factory 902 creates an image asset object 999 in a well known 
location called the Asset Store 940. The image player 942. the audio player 944. and the 
client side application check the Asset Store 940 for matching files and object types. For 
example, the image player 942 would find and play an image asset object 999 inside the 
25 Asset Store 940. 
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With reference to Figure 10, a flow chart is given for outlining the schematics of 
Figure 9. In the step 1002, as the application launches, the Manifest is loaded to the client. 
In step 1004. the application notifies the Asset Manager to load the asset with an ID of 3 for 
example- In step 1006, the Asset Manager searches in the Manifest to see that the asset 
having ID that is equal to 3 and finds the asset's data type to be the image data type. In the 
step 1008, the Asset Manager pulls from the asset registry the image data object factory in 
order to load this particular image data object. In the step 10 10, the image data object 
factory creates an image object representing the image asset in memory. In the step 1012, 
the image data object factory adds the image object to the asset store. 

Extensibility of Asset Types for the Asset Manager: 



As discussed above with reference to Figure 9. the Asset Manager supports a group 
of data object factories, wherein each data object factory responsible for managing a 

1 5 specific type of asset. This particular design of the Asset Manager is a powerful feature of 
the present invention because the support for managing a new type of assets can be easily 
added to the Asset Manager without affecting existing codes. As support for any new type 
of assets is added to the Asset Manager, no change to existing code of the Asset Manager is 
necessary. To add support to any new type of assets, the mere addition of a new data type 

20 factory to the Asset Manager would suffice. Consequently, this design of the Asset 
Manager enables the extensibility of asset types. 

For example, with reference to Figure 9, if a new type of asset that needed to be 
supported by the Asset Manager is a "movie" asset, the developer simply codes the movie 
25 data object factory 905 for inclusion in the group of data object factories for die Asset 

Manager 634. Then the developer makes available a movie player 946 on the client machine 
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for playing die movie assets. New code for a new type of asset can be added without 
affecting any existing codes of the client side application or the Asset Manager. 

Another important aspect of the present invention's data type extensibility is the 
5 ability to support assets of very large sizes such as a streaming data object, without 

affecting existing code. For example, if a very long download of a very large size audio 
asset becomes necessary in running the client side application, the Asset Manager can create 
an illusion that a download has been completed. For a streaming asset such as an audio 
asset, the data object representing this audio asset does not have to be fully instantiated in 
10 the Asset Store by the audio data type factory. That is to say, partially instantiated asset data 
object can be accessed by the client side application as if the asset data object were 
completely instantiated. An audio player can actually begin to play the partially instantiated 
audio data object while the audio data type factory of the Asset Manager continues to 
instantiate the rest of the audio data object 
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The Asset Store and switching Applications: 

The Asset Store plays a facilitating role when an end user is switching between 
different interactive on-line applications. Specifically, the Asset Store can store all of the 
instantiated assets shared by various client side applications. Then, any of these client side 
applications can directly access and use these instantiated assets. 



can I 



With reference to Figure 1 1 . a flow chart is presented to show how the Asset Store 
, be applied for playing the game of JEOPARDY (TM) on-line. For example, if a user 
25 wants to play the game of JEOPARDY (TM) on-line with some other players, the user first 
logs on-line to launch the lobby application of JEOPARDY (TM) to meet potential 
opponents, as outlined in steps 1 102. 1 104 and 1 106. Lobby applications are well known 
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in the online computer gaming arts. Then, in the step 1 108, once the user has decided who 
the other players are, the game application for Jeopardy is launched in the step 1110. 
Finally, as a game is finished in the step III 4, the user can go back to the •lobby" to find 
some other new opponents by launching the lobby application once again, as outlined in 

5 sequential steps of 1118, 1 122, then 1 104. Throughout the whole process, the user would 
have switched between the lobby application and the game application at least twice, as in 
steps 1 124 and 1 122. The Asset Store facilitates the switching between these two 
applications because it retains all of the assets needed by the lobby application when the 
user switches to the game application. So when the user switches back to the lobby 

10 application from the game application, the assets needed by the lobby application are 
already in place in the Asset Store, ready to be used. Similarly, because the Asset Store 
retains all of the assets needed by the game application, as the user switches from the lobby 
application back to the game application, the game application can start right away without 
waiting for its assets to get downloaded. As a result, the Asset Store enhances the user's 

1 5 on-line experience of playing JEOPARDY (TM) because the Asset Store facilitates the 
switching between the lobby application and the game application. 

The foregoing descriptions of specific embodiments of the present invention have 
been presented for purposes of illustration and description. They are not intended to be 

20 exhaustive or to limit the invention to the precise forms disclosed, and obviously many 
modifications and variations are possible in light of the above teaching. The embodiments 
were chosen and described in order to best explain the principles of the invention and its 
practical application, to thereby enable others skilled in the an to best utilize the invention 
and various embodiments with various modification as are suited to the particular use 

25 contemplated. The scope of the invention is intended to be defined by the Claims appended 
hereto and their equivalents. 
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PI .AIMS 

What is claimed is: 

5 l. For a client-server system having a plurality of different client platforms, a 
computer implemented method of generating a client side application of a client-server 
application, said method comprising: 

providing a programming model to be followed by developers for developing said 

client side application; 

10 providing a programming model to be followed by developers for upgrading said 

client side application; 

generating a file associated with said client side application to record an asset 
required by said client side application, and wherein at least one of said assets is a data 
object; and 

15 managing programming logistics for delivering assets required by said client side 

application, and wherein said managing step is executed on at least one client machine of 
said client-server system by a platform-specific system level software component of a client 
machine. 

20 2. The computer implemented method of Claim 1 , wherein said programming model 
requires steps comprising: 

specifying multiple layers of quality for at least one of said assets, wherein said 
asset is a data object having data types selectable from a group comprising video data 
objects, audio data objects, code data objects, data chunk data objects, graphic data objects, 

25 image data objects; 

setting a level of priority for delivering at least one of said assets to said client 

machine; 

25 



BNSDOCID: <WO 0048073A1_IA> 



WO 00/48073 PCT/USOO/03346 



centralizing in said file information associated with at least one of said assets 
required by said client application; 

designing asset delivering policies with said centralized information of said file; and 
providing extensibility of new asset data types, wherein adding new asset data 
5 types does not require changing existing code. 

3 . The computer implemented method of Claim 2, wherein said multiple layers of 
quality comprise: 

a plurality of audio quality layers ranging from low fidelity to high fidelity; and 
10 a plurality of image quality layers ranging from monochrome to full color. 

4 . The computer implemented method of Claim 2. wherein said priority levels are 
ranked by positive integers, and an integer one designates an asset having the highest 
download priority. 

15 

5 . The computer implemented method of Claim 2, wherein for each said asset, said 
centralized information in said file comprises: 

a field of unique H> number. 

a field of data type; and 
20 a field of unique symbolic name. 

6. The computer implemented method of Claim 2, wherein said poUcies need to be 
coded only once for each client platform, and wherein said policies are coded with said 
download priorities specified in said file. 



25 



7. The computer implemented method of Claim 2, wherein said addition of new asset 
data types is implemented by adding a data object factory per one new asset data type in 
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said software component without affecting existing code of said software component and 
said client side application. 

8. The computer implemented method of Claim t, wherein said managing step further 

5 comprises the steps of: 

customizing said asset management software component for each type of client 
platform, wherein said software component manages asset delivery for said client 
application running on each client machine of said client-server system; 
fetching said text file to each said client machine; 
10 prioritizing download ordering of assets with reference to said file; 

unifying multiple storage images of each said asset, wherein each of said storage 
images represents said asset in a distinct persistent memory storage location; 

storing in a central memory location all assets shared by a plurality of client 
applications, wherein said central memory location is termed an Asset Store; 
15 minimizing asset download to avoid intenupting sessions of said client side 

application session; 

9 . The computer implemented method of Claim 8, wherein each said type of client 
platform having characteristics ranges: 
20 from high to low connection bandwidths; 

from large to small dynamic memory sizes; 

from high to low CPU processing speeds; and 

from several to no persistent memory storages. 

25 10. The computer implemented method of Claim 8, wherein said client application can 
start before all of said required assets are available, and wherein said software component 
continues background downloading not-yet downloaded assets. 
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1 1 . The computer implemented method of Claim 8, wherein said multiple storage 
images are uniquely keyed and encoded in addition to said asset located on a HTTP Web 
server, and wherein said software component use available persistently stored storage 
images of said assets to avoid downloading said asset from said HTTP Web server. 

1 2 . The computer implemented method of Claim 8, wherein said shared assets 
minimizes latency in switching between applications. 

1 3 . The computer implemented method of Claim 8, wherein said minimizing step 
comprises: 

searching said text file for all assets having priority levels lower than assets having 
ihe highest priority level; 

downloading said assets having a highest priority level; 

starting said client application as soon as said assets having the highest priority level 
are completely downloaded; 

downloading said lower priority assets in the background while said client 
application is in session; and 

downloading said lower priority assets while said client application is in between 
sessions. 

14. For a client-server system having a plurality of client machines from different client 
rjlatforms, a computer-readable medium having stored thereon instructions for causing said 
client machines to deliver assets required by a client side application of a client-server 
application, comprising code for supporting: 

a plurality of assets fetched from a plurality of servers; 
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a server component generating a file to list said required assets and to specify 

properties associated with said assets; 

a management component for delivering said assets in accordance to said plurality 

of policies; and 

5 an extensible set of data object factories, wherein each of said data object factories 

is associated with a distinct asset data type. 

15. The computer-readable medium of Claim 14. wherein each said asset is a data 
object selectable from a group comprising video data objects, audio data objects, cododata 

10 objects, data chunk data objects, graphic data objects, and image data objects. 

16. The computer-readable medium of Claim 14, wherein said fde is a manifest 
associated with said client side application, said manifest comprising: 

a field of unique ID number for each said asset; 
l5 a field of data type for each said asset; and 

a field of unique symbolic name for each said asset. 

17. The computer-readable medium of Claim 14. wherein the priority levels assignable 
to each of said assets are designated by positive integers, wherein an integer one designates 

20 an asset with the highest download priority level. 

18. The computer-readable medium of Claim 14. wherein for at least one of said client 
machines, said policies specify delivering a necessary platform-specific subset of said 
assets at a necessary point in time in order for said client side application to proceed in a 

25 visually appealing and rational manner. 
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19. The computer-readable medium of Claim 14, wherein said management component 
downloads said assets to at least one of said client machines according to said policies, and 
wherein said management component fetches said assets directly from a plurality of local 
persistent memory locations, provided said assets have been downloaded and stored in said 
plurality of local persistent memory locations. 

20. The computer-readable medium of Claim 14, wherein at least one of said data object 
factories, in the dynamic memory of said client machines, instantiates a data object 
representing an asset with the same data type as said data object. 

21. The computer-readable medium of Claim 20, wherein at least one of said 
instantiated data object is stored in a common dynamic memory location, wherein another 
client side application requiring such said data object can direcdy access said data object 
without any further data object instantiation. 

22. The computer-readable medium of Claim 14, wherein said servers are HTTP Web 
servers. 



23 . The computer-readable medium of Claim 14, further comprising a plurality of 
20 priority levels assigned to said assets. 

24. The computer-readable medium of Claim 14. further comprising a plurality of 
policies for delivering said assets to said client machines. 

25 25 . The computer implemented method of Claim 2, wherein for each said asset, said 
centralized information in said file further comprises: 
a field of URL; 
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a field of quality; 

a field of checksum; and 

a field of download priority level. 

5 26. The computer-readable medium of Claim 14, wherein said file is a manifest 
associated with said client side application, said manifest further comprising: 

a field of URL for each said asset; 

a field of asset file size for each said asset; 

a field of quality for each said asset; 
10 a field of checksum for each said asset; and 

a field of download priority level for each said asset. 
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